Packaging and Deploying Releases

Implementing GitOps principles#

If we’re going to follow the GitOps principles, each release should result in a change of, at a minimum, the tag of the image and the version of the chart. Also, we might want to package the chart in a way that it can be distributed to everyone who needs it. We’ll explore that through a simulation of the development of a new feature that could result in a new release.

Let’s start by creating a new branch, just as we would normally do when working on something new. But first, we need to initialize Git.

Updating values#

Now, let’s imagine that we spent some time writing code and tests and that we validated that the new feature works as expected in a personal development environment and/or in a preview environment created through a pull request. Similarly, assume that we decided to release that feature. The next thing we would probably want to do is change the version of the chart and the application. As we’ve already seen, that information is stored in Chart.yaml, so let’s output that as a refresher.

The output is as follows.

All we have to do is change the version and appVersion values. Normally, we’d do that by opening the file in an editor and changing it there. But, let’s see if we can automate it from a terminal with a few sed commands.

We retrieved the content of go-demo-9/Chart.yaml and piped the output to two sed commands that replaced 0.0.1 with 0.0.2 in both the version and the appVersion fields. The final output was sent to tee, which stored it in the same Chart.yaml file.

The output is as follows.

Now that we’ve replaced the versions, we can turn our attention to the tag that we want to use. It’s one of the variables in values.yaml, so let’s output it. The output, limited to the relevant parts, is as follows.

We’ll replace the value of the image.tag variable with another sed command.

The output, limited to the relevant parts, is as follows.

That’s it. Those are all the modifications we have to do, even though they aren’t mandatory. We could have accomplished the same thing by specifying those values as --set arguments at runtime. But that would result in undocumented and hard to track changes. This way, we can (and we should) push those changes to a Git repository.

Note: Normally, we’d need to build a new image, and we would probably execute several other steps like testing, creating release notes, etc. But that’s not the subject of this chapter, so we’re skipping them. We’ve already built the image vfarcic/go-demo-9:0.0.2, so it’s ready for us to use it.

Validating syntax#

Before we commit to making a new release based on, among other things, that chart, we should validate whether the syntax we’re using is correct and that there are no obvious issues with it. We’ll do that by “linting” the chart.

The output is as follows.

If we ignore the fact that the icon of the chart doesn’t exist, we can conclude that the chart was linted successfully.

Now that the chart seems to be defined correctly, we can package it.

Packaging the charts#

helm package go-demo-9

Note: We should have added --sign to the helm package command. That would provide a way to confirm its authenticity. However, we’d need to create a private key, and we want to stay focused on this subject.

We can see, from the output, that the chart was packaged and saved as go-demo-9-0.0.2.tgz. From now on, we can use that file to apply the chart, instead of pointing to a directory.

We upgraded the go-demo-9 in production with the new release 0.0.2.

What’s the advantage of packaging a chart? It’s just as easy to reference a directory as to use a tgz file. And that would be true if we would always be looking for charts locally. With a package, we can store it remotely. That can be a network drive or an artifact repository, just like the one we used to add MongoDB as a dependency. Those repositories can be purposely built to store Helm charts, such as ChartMuseum. We could also use a generic artifacts repository like Artifactory, or many others.

Let’s move on and check whether the application was upgraded to the new release.

helm --namespace production list

The output is as follows.

We can see that go-demo-9 is now running the second revision and that the app version is 0.0.2.

If we’re still uncertain about whether the application was indeed upgraded, we can retrieve all the information of the chart running in the cluster and confirm that it looks okay using this command.

helm --namespace production \
    get all go-demo-9

Note: We probably got more information than we need. We could have retrieved just hooks, manifests, notes, or values if we were looking for something more specific. In this case, we retrieved everything to show that we can get all the available information.

If, for example, we would like to confirm that the image of the Deployment is correct, we can observe that from the fragment of the output.

Feel free to explore that output in its entirety. We should be able to navigate through it since most of it is either Kubernetes definitions that we’re already familiar with or Helm-specific things, such as variables, that we explored earlier.

Finally, before we move on, we’ll confirm that the new release is indeed reachable by sending a simple curl request.

curl -H "Host: go-demo-9.acme.com" \
  
    "http://$INGRESS_HOST"

This time, the output states that the version is 0.0.2.